Many new services delivered over IP/MPLS networks have certain specific quality requirements, which, if not met make the service unusable, or unacceptable. Two notable examples of such service types are realtime communications over IP, and streaming entertainment over IP. Realtime communications over IP (such as Voice over IP or VoIP) is relatively sensitive to delay and to packet loss. Moderate network quality problems will result in one party having difficulty understanding the other party on a VoIP call; severe problems will drop the communication session, sometimes all communication sessions in progress. Streaming entertainment services over IP such as multicast TV and Video on demand are sensitive to average throughput and packet loss. Moderate network quality problems will result in visual and auditory impairment; severe problems will again result in a loss of the streaming sessions. For the new services described above, it is better to not start a new service session at all, than to start one whose quality cannot be assured, or worse, whose load will result in degradation to services already in use by other customers. Controlling the start of sessions when required is the role of session admission control.
The present invention provides a session admission control solution which solves the three most significant problems of session admission control systems, namely: scaling, network capacity discovery, and incorporation of multicast service sessions. These three aspects according to the invention may be further defined as: (1) mechanisms for negotiating admission control, including the concept of a persistent resource grant referred to as a ‘season ticket’, (2) a calculation of network bottlenecks employing a ‘discovery based’ solution, and (3) an extension to IGMP smart proxy technology to allow multicast replication points, which normally have no way to say “no” to a multicast join request, thereby allowing them to participate in the admission control process.
Session Admission Control (SAC), which is a well understood and documented mechanism, can be of value in controlling the load placed on a network such that overload conditions which would degrade quality are avoided. In the extreme case, a ‘tipping point’ phenomenon can exist, where allowing a single new session to be established can result in catastrophic failure of all sessions currently in progress and contending for an oversubscribed resource.
In general a SAC is involved in determining the resources needed and/or available, and reserving resources for the call. Resources of interest include link bandwidth, but might also deal with Digital Signal Processors, CPU power, and memory. Several of these resources could be constrained at any one or more of the nodes the call will traverse to its destination. RSVP (Resource Reservation Protocol) is a popular IETF standard designed to support resource (such as bandwidth) reservations through networks of varying topologies and media.
Typically, multicast traffic complicates admission control because in standard multicast networks, which use the IGMP (Internet Group Management Protocol) and PIM (Protocol Independent Multicast) families of protocols, there is no way for a multicast replication point to say ‘no’ to a service request, and no mechanism for it to inform other service delivery points that it has enabled the session either. IGMP and PIM are widely used.
There are two main purposes for SAC, which will be expanded in following sections. Broadly, the two main purposes are:    1) To ensure that any given subscriber cannot accidentally cause service quality failure by requesting more simultaneous services then can be supported on their network connection (including multiple instances of a single service such as multiple simultaneous video channels, multiple services, eg. VoIP/Video-telephony, Internet, and video)    2) To allow more graceful service limiting by denying new session setups where the alternative would be wide-scale quality or availability failures for sessions in progress. This is particularly true in the case where there is a long lived but unusual reduction in the available shared capacity to service high bandwidth short-lived sessions.
SAC applies to all services for which a guarantee of throughput is required which typically includes real-time communication services and streaming media services. The guarantee required is normally for a minimum throughput which is to be delivered in every time interval based on the size of the receive client buffer. This can generally be assumed to be a few hundred milliseconds, ie. the minimum rate must be achieved within every 200 ms interval. More rarely, SAC may be applied to other services such as high speed internet access, typically by allowing or denying a request from the user or a 3rd party content/application provider to temporarily boost a user's bandwidth to a higher level for a time interval of defined duration.
The first principal purpose or objective of SAC can be called “Subscriber SAC”. This first purpose is to allow a service provider to ensure that the services which a customer has purchased are available to them with the required quality. SAC per subscriber may be used to limit the number of service instances allowed per customer to that which the customer has paid for and which can be supported by their connection. This form of SAC is inherently dealing with the first mile/first half mile bottleneck, which is typically defined by a per subscriber access rate. In the case of triple play services (data, voice and video), only two of the three triple play services are session based and performance critical—entertainment video and real-time communications. Of these, only video occupies significant bandwidth. Thus a simple solution to implement subscriber SAC today, is simply to do admission control at an application level on video sessions. VoIP, if present, occupies an insignificant amount of bandwidth and therefore can be safely assumed to be always in use for the purposes of calculating bandwidth available for Video. That is, every service is managed separately, and video on demand and video broadcast are the only ones that really counts from a SAC perspective. A future subscriber SAC requirement is to sell more services to a customer, where those services are occasionally used, and which collectively would use more bandwidth than the physical capacity that exists. For example, it might be that a customer has enough bandwidth for video telephony, or streaming video, but not both at the same time. This is different from the case above, because it is now necessary to coordinate sessions control across more than one service. SAC in this instance allows the service provider to sell the customer both services, as long as the customer understands that they can do one or the other but not both at the same time. (Or in a more nuanced version, it might allow them to do both simultaneously, but not at peak quality levels).
The second principal purpose or objective of SAC can be called “Overload SAC”. This second value to SAC is to deal with abnormal-demand load conditions in the shared aggregation network, by denying new session requests where the alternative would have been serious quality failures for the sessions in progress. That is to say, the probability of quality impairment for all customers is reduced by blocking a few customers. For example, if some special live video event was only available by unicast and a very high proportion of subscribers attempted to access the event, then this could cause a peak demand which could not be met. The result might be high levels of packet loss which cause very significant quality degradation and potentially crashed video sessions.
IP Multicast is a particular subset of the streaming entertainment video services which is unique in that the point where a subscriber attaches to a service is normally distributed and has no mechanism for declining a service request. IP Multicast provides a bandwidth effective mechanism for delivery of continuous multimedia streams such as video and audio to a group of receivers across a data network using data replication point(s) close to the receivers from the source.
In the network access segment of an IP network, hosts request a multicast channel from their upstream multicast router usually using the IGMP protocol, although other protocols such as SIP or RTSP, or even XML (Web services) can potentially be used. The first hop (subscriber aggregation) multicast router, most likely an IGMP router or proxy, processes the channel request from its receivers and instantiates required changes, ie. ‘Joining’ a subscriber to a requested channel or ‘Leaving’ a channel.
The mechanism that will be described here can be referred to as provider-signaled SAC where a content or application provider (or proxy) sees the request for a service instance and performs a check to verify that the service instance should be allowed. The basic mechanism by which the SAC function should occur is as follows:    1. Customer requests service instance. (This will normally occur automatically as part of service usage; the phone goes off hook and digits are dialed, the Set-top box is turned on and a channel is requested, etc.)    2. Service instance received by server or proxy server. (In the application/service provider domain, not network domain)    3. Service request validated against ‘local’ subscriber data (eg has the subscriber paid for this type or number of service instances?)    4. Application server generates resource reservation request and sends to a session admission control policy decision point application for validation.    5. The first point at which a decision is made is a local and distributed decision point. This may be functionality built into an application, or alternatively the application may reference a local admission control proxy application (typically running on the same application server) which will be called SAC-M. The latter ‘external’ SAC-M option allows implementation of the system with minimal application changes. If the functionality is built into the application, this is effectively implementing the SAC-M proxy function in the application; further description will describe this SAC-M as if it is external to the application. SAC-M implemented external to the application also allows the SAC-M to abstract the behavior of the SAC-PDP from the application.    6. If a local distributed decision cannot be made at the SAC-M, then the admission request is passed on to a more centralized admission control decision point known as a SAC-PDP (Session Admission Control Policy Decision Point).    7. Note that the SAC decision may be made in the decentralized SAC-M node, or the centralized SAC-PDP node. The local SAC-M applies local rules, such as ‘have I already obtained permission to grant resources within a certain range and is that permission still valid’, and also interfaces with the SAC-PDP node when required, such as when an open permission does not exist on the SAC-M.    8. If the request is forwarded to the SAC-PDP, it checks the request against bandwidth already committed and available for that subscriber.    9. SAC-PDP may also check the request against bandwidth already committed and available for the aggregate of which that subscriber is a part. (eg. 2nd mile services and BW)    10. SAC-PDP may also check the request against the bandwidth already committed and available for that service type (eg. video service in region x)    11. The bandwidth reservation response is returned to the application server.    12. Application server signals the user with the appropriate functioning service or ‘busy tone’ equivalent.    13. On application session termination or time-out the application server advises the SAC-PDP to tear down the reservation.
It is possible to enhance the standard multicast subscription process to verify that a host requesting a particular channel is authorized to receive the requested channel and perform a session admission control check to verify that there exist sufficient bandwidth and processing resources for granting the requested channel to the requesting host.
Avoiding congestion through SAC is achieved through comparing the current demand load against the available capacity at each network bottleneck and declining a service request if admitting such a request would overload the bottleneck. Although there may be multiple bottlenecks in series, these can usually be reduced to a simpler set. This is desirable to minimize complexity. Bottlenecks can usually be condensed down to just three:    1) The smallest of all constraints which applies to a single subscriber;    2) A bottleneck which applies to a set of subscribers; and    3) A bottleneck which applies to a service or application type.
Bottlenecks can play a role in the SAC decision making in one of two modes, dimensioned or discovered.
Dimensioned bottlenecks have a management interface by which the relevant bottleneck dimensions can be learned. For example the sync rate of a DSL line can be learned by querying or being told by the DSLAM management system. Dimensioned bottlenecks have a known quantum of bandwidth which may change over time, but relatively infrequently.
Discovered bottlenecks come from a portion of the network which is not directly observable from a management perspective, but whose behavior can be observed and gauged in near real-time.
There are three general approaches to SAC in a packet network: Local limit SAC, Resource reservation based SAC, and measurement based SAC.
Local SAC mechanisms function on the first hop multicast router, gateway, access concentrator or aggregation element. The SAC decision is based on nodal information such as the state of the outgoing LAN or WAN link. If the local packet network link is down, there is no point in executing complex decision logic based on the state of the rest of the network, because that network is unreachable. Local mechanisms include configuration items to disallow more than a fixed number of calls. For example, if the network designer already knows that no more than two multicast channels can fit across the access LAN link because of bandwidth limitations, then local SAC mechanisms allow the designer to configure the local node to allow no more than two multicast channels simultaneously.
Measurement-based SAC techniques look ahead into the packet network to gauge the state of the network in order to determine whether to allow a new call. Gauging the state of the network implies sending probes to the destination IP address (usually the terminating gateway or terminating gatekeeper) that will return to the outgoing gateway with some measured information on the conditions the probe found while traversing the network to the destination. For example from a large enough sample of the delay for different sized packets being transmitted between two nodes the available bandwidth can be inferred
In addition, a subscriber's request to initiate a service session is typically evaluated using a set of authorization policies, such as security/authorization policies, and this authorization check precedes or can be considered part of the SAC determination. The subscriber request authorization functionality is explained in detail in U.S. patent application Ser. No. 11/212,870 filed Aug. 29, 2005, the contents of which are incorporated herein by reference.
There is considerable prior art on point-to-point SAC in general, but little for point-to-multipoint sessions. The prior art that is widely used today is based on a local SAC mechanism to limit the number of multicast channels that are allowed per IP interface, or per physical link. This mechanism, known as “IGMP State Limit” is available in most popular multicast routers today and allows a service provider to specify the number of IGMP groups per port and/or per interface to support multicast SAC. Membership requests in excess of the configured limits will not be entered in the IGMP state tables, and traffic for those excess membership requests will not be forwarded. Using this “IGMP State Limit”, service providers may preserve the quality of service for all multicast streams on a given port/interface by disallowing new streams to join that would violate the traffic engineered goals. Also, the IGMP State Limit feature provides protection against denial of service (DoS) attacks caused by Internet Group Management Protocol (IGMP) packets.
The “IGMP State Limit” does not allow admission control decisions to span across multiple services, or even across both multicast and unicast video. Even for multicast alone control, the “IGMP State Limit” SAC that is popular today has the following drawbacks:    1—It does not differentiate between high-bandwidth multicast channels, such as high-definition TV, and low-bandwidth multicast channels such as music or text conferencing. A network engineer is left with no option but to assume that all channels are high-bandwidth channels (worst case) when engineering the IGMP State Limit.    2—The “IGMP State Limit” feature provides a SAC for IGMP, but not for multicast subscriptions in general. In some scenarios, SIP and/or RTSP is used to request a multicast channel and there is a need for a SIP SAC in those scenarios. In the future, Web services may be used for multicast channel subscriptions and there will be a need for another SAC to handle them.    3—Existing IGMP SAC features have no way to present to a subscriber the reason for which a subscription is denied. IGMP does not currently provide message formats and error codes for replying to a host after a subscription is denied.
RSVP offers a resource reservation based SAC for point-to-point and point-to-multipoint sessions on a router. Although RSVP offers a point-to-multipoint SAC functionality, it is not typically used with multicast in the access network due to its complexity and limited scalability. It is not popular in multi-service admission control in the access and aggregation networks because it is too complex. RSVP performs end-to-end resource reservation for point-to-multipoint sessions, which is not needed for multicast SAC in the access and aggregation network segments because typically most of the multimedia channels are always forwarded to the access multicast router. RSVP based SAC is very complicated and relies on end-to-end network compliance and interoperability in a way that makes it difficult to deploy reliably in real network deployments.
Both of the above SAC approaches do not react to changes in the active bandwidth available on a DSL (Digital Subscriber Line), for example due to copper outside wiring changes, interference, etc. As the effective available bandwidth changes, the SAC mechanisms described above do not adapt to optimize service delivery with a guaranteed service QoS within the newly changed available bandwidth.
Prior implementations of the SAC functionality have seen limited deployment because they did not address a number of key problems. More specifically, they did not scale well, they had no mechanism for discovering the topology and dimensioning of the network, and they did not allow admission control over multicast sessions. All three of these problems are addressed by this invention.
This invention aims at providing a SAC mechanism for handling multicast channel subscriptions and unicast sessions requests. When deployed in a typically oversubscribed network access segment, an admission control enforcement point such as a multicast router uses this SAC functionality to avoid congesting access links which carry quality of service (QoS) sensitive services. The SAC method described here may evaluate channel requests that would typically adhere to one of the multicast or unicast session establishment protocols: IGMP (Internet Group Membership Protocol), SIP (Session Initiation Protocol), RTSP (Real-Time Streaming Protocol), or Web services SOAP multicast subscription.